home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0083.001 < prev    next >
Text File  |  1995-06-17  |  38KB  |  876 lines
  1.  
  2.   | Document: FSC-0083
  3.   | Version:  001
  4.   | Date:     17 June 1995
  5.   |
  6.   | Jonathan de Boyne Pollard, FIDONET#2:440/4.0
  7.  
  8.             A proposed standard for message IDs on FTN systems.
  9.  
  10.                                     by
  11.  
  12.                 Jonathan de Boyne Pollard, FIDONET#2:440/4.0
  13.  
  14.                         Version 0.02, Sun 19950507
  15.  
  16.     This document is (c) Copyright 1995 Jonathan de Boyne Pollard, all
  17.     rights reserved.  Originally written on Tuesday 19950131.
  18.  
  19.     Permission is hereby granted to copy and use this document without
  20.     modification in any way that you see fit, provided that you do not
  21.     attempt to make money from it, and that you understand that I take no
  22.     responsibility whatsoever for any effect that it may have on your
  23.     machine, data, marital status, or cat.
  24.  
  25.     Especial permission to freely use and redistribute this document in
  26.     its original form is given to developers of FTN softwares and whatever
  27.     FIDONET Technical Standards bodies may exist from time to time.
  28.  
  29.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  30. ÍÍÍ 0.0 Definition of terms ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  31.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  32.  
  33.     This document assumes familiarity with several terms in common use in
  34.     discussion of mail systems, such as `User Agent', `Message Transport
  35.     Agent', and so forth.
  36.  
  37.     Robot mail programs qualify as UAs, incidentally.
  38.  
  39.     0.1 Knackered Backward Form
  40.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  41.  
  42.     This specification uses a modified BNF notation for discussion of
  43.     textual representation of message IDs.
  44.  
  45.     Literal syntax elements (terminal nodes of the grammar) are enclosed
  46.     in single quotes.
  47.  
  48.         'MSGID:'    '@'    '<'      '"'
  49.  
  50.     Non-terminal nodes are enclosed in angle brackets (greater than and
  51.     less then signs).
  52.  
  53.         <quoted-text>        <hex-text>        <q-p-site-identifier>
  54.  
  55.     Production rules comprise a non-terminal, followed by productions.
  56.     Alternate productions for the same non-terminal are separated by a
  57.     vertical bar.
  58.  
  59.         <qtext-chars> ::=
  60.                   '"' '"'
  61.                 | <any-character-except-quotes-NUL-or-CR>
  62.  
  63.     Optional sequences within a production are indicated in two ways.
  64.     Square brackets enclose a sequence that may occur exactly once or not
  65.     at all.
  66.  
  67.         [ '@' <dns-name> ':' ]
  68.  
  69.     Curly braces enclose a sequence that may be repeated any number of
  70.     times.    A leading numeric prefix (usually 0 or 1) indicates the
  71.     minimum number of repetitions.
  72.  
  73.         1*{ <hex-character> }
  74.  
  75.     0.1.1 Some standard production rules
  76.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  77.  
  78.         <whitespace-char> ::= <tab> | <space>
  79.  
  80.         <whitespace> ::= 1*{ <whitespace-char> }
  81.  
  82.         <hex-character> ::=
  83.             '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'|
  84.             'A'|'B'|'C'|'D'|'E'|'F'|
  85.             'a'|'b'|'c'|'d'|'e'|'f'
  86.  
  87.         <upper-hex-char> ::=
  88.             '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'|'A'|'B'|'C'|'D'|'E'|'F'
  89.  
  90.         <qtext-char> ::=
  91.                 '"' '"'
  92.               | <any-ASCII-character-except-quotes-NUL-or-CR>
  93.  
  94.         <quoted-text> ::= '"' 0*{ <qtext-char> } '"'
  95.  
  96.         <quoted-char> ::=
  97.                 <any-ASCII-character-except-quotes-backslash-NUL-or-CR>
  98.               | '\' <any-ASCII-character-execpt-NUL-or-CR>
  99.  
  100.         <quoted-string> ::= '"' 0*{ <quoted-char> } '"'
  101.  
  102.         <word> ::= 1*{ <any-ASCII-character-above-SPACE-and-below-DEL> }
  103.  
  104.     Note the difference between the two forms of quoting.  <quoted-text>
  105.     is a string with embedded quotation marks represented by double
  106.     quotation marks (the way that most BASIC languages do).  However,
  107.     <quoted-string> is a string with all quotation marks and backslashes
  108.     (and, indeed, any other character) escaped by the backslash character,
  109.     in the style of the C and C++ languages.
  110.  
  111.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  112. ÍÍÍ 1.0 Definition and use of message IDs ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  113.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  114.  
  115.     For the purposes of this document, the network is considered to form a
  116.     vast distributed database of messages, which uses replication and
  117.     store and forward distribution to ensure that all carriers of the
  118.     database are kept up to date.  Every message, whether netmail or
  119.     echomail, carries a primary message ID that uniquely identifies it,
  120.     and zero or more reference message IDs that uniquely identify any
  121.     messages that it refers to.
  122.  
  123.     A primary message ID is a globally unique key that is used for
  124.     uniquely identifying any single given mail message in the database
  125.     (that is, counting all replicas of a message over all of the network
  126.     as "one").  The reference message IDs are used by user agents to form
  127.     a reply graph, allowing the the user to easily navigate the
  128.     messagebase.
  129.  
  130.     Message transport protocols may require the data in a message ID to be
  131.     encoded so that it may be safely transported.  This standard
  132.     distinguishes between the "underlying" message IDs and the encoded
  133.     forms.  This chapter discusses the underlying message IDs and the
  134.     concepts behind them without reference to a particular encoding, and
  135.     subsequent chapters discuss the various encoded forms.
  136.  
  137.     1.1 Components of a message ID
  138.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  139.  
  140.     A message ID comprises two parts, namely a site identifier and a local
  141.     part.  Both of these parts are arbitrary 8-bit binary data, that
  142.     implementations are free to store in any way they choose, but which
  143.     they should never alter.  There are no distinguished characters in
  144.     either the site identifier or local part, especially not terminating
  145.     characters.  So implementations must usually store an additional
  146.     length count for both.
  147.  
  148.     The "minimum maximum" lengths for the site ID and local part are 64
  149.     octets each, and conforming implementations may not impose shorter
  150.     maximum length restrictions.  In fact, implementations are encouraged
  151.     to impose no length restrictions on message IDs whatsoever (for
  152.     example, it is not unreasonable to expect site IDs to exceed 256
  153.     octets on occasion).
  154.  
  155.     1.2 Preservation of uniqueness
  156.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  157.  
  158.     A site that creates messages (by entering them into the distributed
  159.     database) must also issue message IDs, and must ensure that the global
  160.     uniqueness property of message IDs is preserved.
  161.  
  162.     A site MUST ensure that it issues unique local parts to individual
  163.     messages.  Two or more sites may not have the same site identifier,
  164.     unless they *all* co-operate to ensure that they do not issue
  165.     duplicate local parts.
  166.  
  167.     The administrative procedures necessary to obtain a unique site
  168.     identifier are beyond the scope of this document.  Usually site
  169.     identifiers will be FTN 5D addresses, or fully qualified DNS names,
  170.     because administrative procedures for assigning such are already in
  171.     place.  However, they are not restricted to be such.
  172.  
  173.     The means by which a site invents new local parts is beyond the scope
  174.     of this document.  A discussion of some example options for
  175.     implementors to consider is given in an appendix.
  176.  
  177.     1.3 Reference message IDs
  178.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  179.  
  180.     Reference message IDs in a message denote messages to which it is
  181.     related, comprising a "local subset" of the overall reply graph (i.e.
  182.     the direct and indirect ancestors of the message), which each message
  183.     carries around with it.
  184.  
  185.     Carrying around multiple reference message IDs provides overlap,
  186.     allowing for the overall reply graph to be reconstructed even in the
  187.     absence of intermediate messages (if they had expired, or had not yet
  188.     arrived due to propagation lag, for example).
  189.  
  190.     UAs that conform to this standard MUST ensure that only messages that
  191.     start new threads (i.e. messages entered into the network not in
  192.     response to any existing message) have no reference message IDs.
  193.  
  194.     All other messages that they create MUST contain at least one
  195.     reference message ID, being that of the message that is being
  196.     responded to.
  197.  
  198.     [[ Luckily, schemes already in existence mean that in practice
  199.        non-conforming User Agents will generally preserve this single back
  200.        link, as well.  ]]
  201.  
  202.     When responding to a message, user agents must create the reference
  203.     message ID list of the response by taking the list of reference
  204.     message IDs from the original message, and appending the primary
  205.     message ID of the original message to the tail.
  206.  
  207.     A reference message ID list should not be truncated, unless transport
  208.     or storage limitations are in danger of being exceeded.  In which
  209.     case, message IDs may only be removed from the head of the list.
  210.     Removing from the tail would eliminate links to immediate ancestor
  211.     messages, and removing from the middle would alter the reply graph.
  212.  
  213.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  214. ÍÍÍ 2.0 Quoted printable encoding for storing 8-bit data in 7-bit transports ÍÍ
  215.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  216.  
  217.     To encode the 8-bit data in message IDs for transport by 7-bit
  218.     transport layers, we use a variation on the widely used Quoted
  219.     Printable form [RFC1521] [RFC1522].
  220.  
  221.     2.1 Grammar of Quoted Printable encoding
  222.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  223.  
  224.     The grammar of the 7-bit encoding of 8-bit data in a quoted printable
  225.     word is as follows.
  226.  
  227.         <q-p-word> ::=
  228.                 <word>
  229.               | <quoted-text>
  230.               | [ '=' ] 1*{ <q-p-character> } [ '=' ]
  231.  
  232.         <q-p-character} ::=
  233.                 <any-ASCII-character-bar-ctls-wspace-quote-and-equals>
  234.               | <q-p-quoted-char>
  235.  
  236.         <q-p-quoted-char> ::= '=' <upper-hex-char> <upper-hex-char>
  237.  
  238.     2.2 Conversion from 8-bit to 7-bit
  239.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  240.  
  241.     Rule #1 (non-quoted transparent 7-bit): Where the 8-bit data consist
  242.         of nothing but ASCII characters above SPACE and below DEL, they
  243.         may be copied literally to the 7-bit representation.
  244.  
  245.     Rule #2 (quoted transparent 7-bit):  Where the 8-bit data consist of
  246.         nothing but ASCII characters except CR and NUL, they may be
  247.         converted to the 7-bit representation by enclosing them in quotes,
  248.         and escaping every embedded quotation mark with a second quotation
  249.         mark.
  250.  
  251.     Rule #3 (8-bit quoted): Where the 8-bit data contain CR or NUL, or any
  252.         non-ASCII characters, they are converted to a 7-bit representation
  253.         in two stages.
  254.  
  255.         Firstly, all non-ASCII characters, all ASCII control characters,
  256.         SPACE, DEL, '"', and '=', are converted to "quoted" form.  Quoted
  257.         form is an '=' character followed by the hexadecimal value of the
  258.         character represented as two uppercase hexadecimal digits.
  259.  
  260.         Secondly, the entire string is then enclosed by one leading and
  261.         one trailing '=' character.
  262.  
  263.     2.3 Conversion from 7-bit to 8-bit
  264.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  265.  
  266.     Where the 7-bit field is delimited by equals signs, it is a fair bet
  267.     that it comprises 8-bit data to which Rule 3 has been applied.
  268.     However, it is possible that sites in the 7-bit world may produce data
  269.     with leading and trailing equals signs.
  270.  
  271.     Reverse of Rule #3 : If, after stripping the leading and trailing '=',
  272.         the remaining text can be converted back using the reverse of Rule
  273.         3, then that 8-bit data is the actual message ID.  Otherwise the
  274.         reverse of Rule 2 should be applied to the original 7-bit data.
  275.  
  276.     Reverse of Rule #2 : If the 7-bit data are enclosed by quotes the
  277.         reverse of Rule 2 should be applied to remove the enclsing quotes
  278.         and any embedded quotes (8-bit form does not have delimiter
  279.         characters and so does not require quoting).  Otherwise the
  280.         reverse of Rule 1 should be applied.
  281.  
  282.     Reverse of Rule #1 : The 7-bit data are copied to the 8-bit data.
  283.  
  284.     2.4 Rationale
  285.     ÄÄÄÄÄÄÄÄÄÄÄÄÄ
  286.  
  287.     The intention is that <q-p-word> tokens will not be parsed as separate
  288.     words by most 7-bit grammars.  The elimination of quotes, whitespace,
  289.     and control characters by Rule 3 is part of achieving this.
  290.  
  291.     Rules 1 and 2 allow message IDs created by 7-bit standards to enter
  292.     and travel within the 8-bit world, and be restored to their original
  293.     form when they return to the 7-bit world.  Returning 7-bit message IDs
  294.     to their original form means that 7-bit duplicate checking is not
  295.     broken by 8-bit gateways.
  296.  
  297.     The unfortunate side-effect is that any 8-bit data generated in the
  298.     7-bit world will be returned to the 7-bit world as 7-bit data in Q-P
  299.     encoded form.  However, the original 8-bit data are unlikely to work
  300.     in the 7-bit world in the first place, so this is no great loss.
  301.  
  302.     Rule 3 is the most general rule of the three.  Rule 3 applies to true
  303.     8-bit message IDs generated in the 8-bit world that use 8-bit
  304.     characters, allowing them to travel across the 7-bit world with a
  305.     reasonable chance of remaining intact.
  306.  
  307.     The elimination of the equals sign by Rule 3, replacing it with its
  308.     Q-P encoding, ensures that the decoding process can assume that an
  309.     equals sign not followed by two uppercase hex characters is not a
  310.     valid Rule 3 encoding, and so fall back to decoding Rule 2.
  311.  
  312.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  313. ÍÍÍ 3.0 Storage of message IDs in type 2.0, 2.0+, and 2.2 message packets ÍÍÍÍÍ
  314.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  315.  
  316.     Type 2.0 message packets [FTS0001], type 2.0+ message packets
  317.     [FSC0039], and type 2.2 message packets [FSC0045] are used for message
  318.     transport over much of FIDONET.  They do not have space in their
  319.     message headers available for message IDs (along with a lot of other
  320.     things), therefore message IDs must be transferred to the body of the
  321.     message for transport in these forms, and retrieved from the body of
  322.     the message afterwards.
  323.  
  324.     The existing "kludge line" mechanisms [FSC0068] are used to do this.
  325.  
  326.     There are two concerns here.
  327.  
  328.     Firstly, it is preferable that as much of the reply graph as possible
  329.     is preserved, even in the face of tools that use existing MSGID/REPLY
  330.     schemes [FTS0009].
  331.  
  332.     Secondly, message IDs are 8 bit data, and must be encoded into a 7-bit
  333.     form that will be reliably transported in the bodies of type 2.0,
  334.     2.0+, and 2.2 message packets.
  335.  
  336.     3.1 Conversion to and from kludge lines
  337.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  338.  
  339.     The primary message ID of a message is stored to and retrieved from a
  340.     "MSGID:" kludge line.
  341.  
  342.     All of the reference message IDs of a message are stored, in order
  343.     from first to last, in a single "REFER:" kludge line.  The last
  344.     reference message ID of a message (its immediate ancestor, in other
  345.     words) is stored in a "REPLY:" kludge line.  Note that the information
  346.     in the "REFER:" kludge line is a superset of the information in the
  347.     "REPLY:" kludge line.
  348.  
  349.     If a message has zero reference message IDs (it is the start of a new
  350.     thread), then the "REFER:" and "REPLY:" kludge lines are omitted.
  351.  
  352.     If, upon decoding from type 2.0, 2.0+, or 2.2 message transport
  353.     format, a "REFER:" kludge line exists, then its contents are assumed
  354.     to be the complete list of reference message IDs (in encoded form) for
  355.     the message, and the "REPLY:" kludge line is ignored.  Otherwise, the
  356.     content of the "REPLY:" kludge line (if any) is used for the single
  357.     reference message ID of the message.
  358.  
  359.     3.2 Compatibility with existing MSGID/REPLY schemes
  360.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  361.  
  362.     There are two compatibility considerations.  It is important that
  363.     encoded message IDs be correctly parsed by implementations using older
  364.     less versatile standards.  It is also important that implementations
  365.     expecting older MSGID/REPLY pairs will destroy as little linking
  366.     information as possible.
  367.  
  368.     3.2.1 Grammar considerations
  369.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  370.  
  371.     There are two valid interpretations of FTS-0009, both of which
  372.     (should) use the following grammar :
  373.  
  374.         <msgid> ::= <soh> 'MSGID: ' <address-text> <whitespace> <hex-text>
  375.         <reply> ::=    <soh> 'REPLY: ' <address-text> <whitespace> <hex-text>
  376.  
  377.         <soh> ::= ASCII SOH character
  378.         <address-text> ::= <quoted-text> | <word>
  379.         <hex-text> ::= 1*{ <hex-character> }
  380.  
  381.     The "VFIDO" interpretation assumes that MSGID/REPLY kludges are the
  382.     textual representation of an (address, number) ordered pair.  Systems
  383.     using this interpretation may change the case of <hex-text> or may
  384.     renormalise <quoted-text> if they find it to be a FTN 5D address.
  385.  
  386.     Message IDs from this standard that are stored in MSGID/REPLY kludges
  387.     will be mangled by software applying the VFIDO interpretation of
  388.     FTS-0009.  Such software is not compatible with this standard.
  389.  
  390.     The "Mark Kimes" interpretation assumes that MSGID/REPLY kludges are
  391.     text separated by whitespace, and preserves the contents of
  392.     <quoted-text> and <hex-text> without change.
  393.  
  394.     The encoding scheme outlined in section 2.2 produces two whitespace
  395.     separated text fields.    So software applying the "Mark Kimes"
  396.     interpretation of FTS-0009 will not mangle the encoded message IDs.
  397.  
  398.     In many cases, softwares using the "Mark Kimes" interpretation will in
  399.     fact parse <hex-text> as
  400.  
  401.         <hex-text> ::= <word>
  402.  
  403.     As long as software applying the "Mark Kimes" interpretation of
  404.     FTS-0009 is not written to truncate either field, or complain about a
  405.     non-numeric <hex-text> portion, it is compatible with this standard.
  406.  
  407.     3.2.2 Reply linking
  408.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  409.  
  410.     FTS-0009 implementations will generate MSGID kludges, transfer the
  411.     content (Mark Kimes interpretation) of the MSGID kludge data of an
  412.     original message into the REPLY data of a response message, and will
  413.     not generate a REFER kludge.
  414.  
  415.     So reply linking will be preserved, but reference information beyond
  416.     the immediate ancestor of a message will be lost.
  417.  
  418.     3.3 Quoted printable encoding
  419.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  420.  
  421.     The 8-bit data in message IDs is encoded into 7-bit MSGID/REPLY data
  422.     for transport in type 2.0, 2.0+, and 2.2 message packets by using the
  423.     quoted printable encoding outlined in chapter 2, along with the
  424.     following grammar.
  425.  
  426.         <msgid> ::= <soh> 'MSGID: ' <7-bit-encoding>
  427.         <reply> ::= <soh> 'REPLY: ' <7-bit-encoding>
  428.         <refer> ::= <soh> 'REFER: '
  429.                         <7-bit-encoding> 0*{ <whitespace> <7-bit-encoding> }
  430.  
  431.         <7-bit-encoding> ::= <q-p-site-ID> <whitespace> <q-p-local-part>
  432.  
  433.         <q-p-site-ID> ::= <q-p-word>
  434.         <q-p-local-part> ::= <q-p-word>
  435.  
  436.     Applying Rule 1 of Q-P encoding to local parts is safe as long as
  437.     <hex-text> (from the FTS-0009 grammar) is in actuality treated as
  438.     <word> by most implementations, as outlined in the compatibility
  439.     notes.
  440.  
  441.     Rule 2 should not be applied to local parts, because the grammar of
  442.     FTS-0009 does not allow for quoted text in the <hex-text> portion.
  443.  
  444.     The restrictions in Rule 3 have deliberate effect here.  FTS-0009
  445.     sites will rarely produce data with leading and trailing equals signs,
  446.     so reversing Rule 3 will be unlikely to be subject to spurious data.
  447.     In theory, relaxing Rule 3 reversal to include decoding lowercase
  448.     hexadecimal as well as uppercase hexadecimal would mean that sites
  449.     that convert the case of MSGID/REPLY (as part of the "VFIDO"
  450.     interpretation) would not break Q-P encoding.
  451.  
  452.     However, the "VFIDO" interpretation will usually do far more damage
  453.     than simple case conversion, which will be impossible to restore.
  454.     Rather than attempt the reverse conversion (which could have the
  455.     undesirable effect of causing different messages to end up with the
  456.     same 8-bit message ID if the local part were truncated to eight
  457.     characters in the 7-bit world), any "VFIDO" mangling that occurs will
  458.     prevent Q-P decoding from succeeding.
  459.  
  460.     This means that 8-bit message IDs that look like incomplete or damaged
  461.     Q-P encodings are not gateway problems, but are more likely to be the
  462.     result of a site using the "VFIDO" interpretation in the 7-bit world.
  463.  
  464.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  465. ÍÍÍ 4.0 Storage of message IDs in type 2.3 message packets ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  466.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  467.  
  468.     The storage format of type 2.3 messages (so-called "extensible type 2"
  469.     [TYPE2EXT]) provides space in the message headers for both a primary
  470.     message ID and an arbitrary list of reference message IDs.
  471.  
  472.     All message IDs are stored as 8-bit binary strings, using length
  473.     counts rather than delimiters.    Therefore message IDs can be stored
  474.     directly in type 2.3 messages.
  475.  
  476.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  477. ÍÍÍ 5.0 Storage of message IDs in type 3.x message packets ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  478.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  479.  
  480.     There is such a wide variety of type 3 message formats that this
  481.     standard doesn't hope to cover them all.
  482.  
  483.     For those with binary "chunks", chunk types 'PMID' (primary message
  484.     ID) and 'RFER' (reference message IDs) are expected to have the
  485.     following form :
  486.  
  487.      ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
  488.      ³ Length of site identifier                    WORD32 ³
  489.      ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  490.      ³ Site identifider                              ...   ³
  491.      ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  492.      ³ Length of local part                         WORD32 ³
  493.      ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  494.      ³ Local part                                     ...   ³
  495.      ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
  496.  
  497.     Those schemes that use text format headers and require field
  498.     delimiters may care to use the Q-P encoding outlined in chapter 2.
  499.  
  500.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  501. ÍÍÍ 6.0 Storage of message IDs in RFC822 and RFC1036 messages ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  502.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  503.  
  504.     The grammar of "Internet" messages is defined by the standards for
  505.     ARPA text messages [RFC0822] and for Usenet news messages [RFC1036].
  506.  
  507.     6.1 Restrictions on interconversion
  508.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  509.  
  510.     Interconversion between a FIDO message ID and an RFC822 Message-ID is
  511.     restricted by several factors.  The major factor is that RFC0822
  512.     actually places greater restrictions upon Message-IDs than this
  513.     standard does upon FIDO message IDs (in part because this standard is
  514.     designed to also be able to handle X.400 message identifiers and
  515.     others transparently as well).  It mandates that the <address> portion
  516.     of a Message-ID be a valid DNS name.
  517.  
  518.     A secondary factor is reversibility, in that many gateways exist
  519.     between FTN and RFC822, and so message IDs that cross the boundary
  520.     more than once will retain as much of their original ID information as
  521.     possible.  There is more information contained within a FIDO message
  522.     ID than in an RFC822 Message-ID.  In particular, the <address>
  523.     portions of RFC822 Message-IDs are not case sensitive, whereas the
  524.     site ID of a FIDO message ID is treated as 8-bit data for the purposes
  525.     of comparison.
  526.  
  527.     These are handled by restricting the allowable conversions that a
  528.     conformant gateway may use on a message ID, by ensuring that all of
  529.     the FIDO information is not lost when converted to the (narrower
  530.     bandwidth) RFC822 Message-ID format, and by allowing gateway softwares
  531.     to infer a meaning from the site identifier portion of a message ID.
  532.  
  533.     This is the *only* part of this standard where it is allowed for
  534.     softwares to place a meaning on the site identifier of a message ID.
  535.  
  536.     6.1 Converting to RFC822 form
  537.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  538.  
  539.     6.1.1 Site identifier recognition
  540.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  541.  
  542.     Gateway softwares are allowed to examine a site identifier of a
  543.     message ID and determine whether it is in a format that they recognise
  544.     or not.  This standard specifies what gateway softwares should do when
  545.     they encounter a site identifier that is a recognisable DNS name or
  546.     one that is recognisable FIDO 5D address, and what form the DNS name
  547.     for RFC822 must take.
  548.  
  549.     Site identifiers that are not FIDO 5D addresses are really beyond the
  550.     scope of FIDONET documentation.  If an implementation recognises
  551.     another form of site identifier (such as X.400 O/R addresses) then it
  552.     is free to translate that site identifier to and from DNS form, as
  553.     long as it knows how (there are RFCs on how to perform X.400
  554.     conversion).
  555.  
  556.     This message ID standard imposes no restrictions on site identifiers,
  557.     allowing any scheme to be administered on FIDONET.  It is therefore up
  558.     to the site identification schemes themselves to provide their own
  559.     mappings to and from DNS names.
  560.  
  561.     Gateways are free to drop messages with message IDs that they do not
  562.     understand how to convert.  Both the FIDONET and RFC worlds depend
  563.     heavily upon message IDs for detecting messages duplicates, and so it
  564.     is better that a gateway should NOT distribute messages with message
  565.     ID formats that it doesn't understand how to convert to RFC822 form,
  566.     rather than that it does so incorrectly.
  567.  
  568.     6.1.1.1 Site identifiers that are DNS names
  569.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  570.  
  571.     If the site identifier of a message ID can be parsed as a legal DNS
  572.     name according to the grammar of RFC822 then, even if it cannot be
  573.     resolved to an IP address or MX record, it must be used as the domain
  574.     name of the RFC message ID, and the local part must be passed through
  575.     unchanged.
  576.  
  577.     This allows for RFC message IDs to enter and leave 8-bit FIDONET
  578.     without change, even via gateways that have no knowledge of or
  579.     connectivity to the originating RFC host.
  580.  
  581.     6.1.1.2 Site identifiers that are FIDO 5D addresses
  582.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  583.  
  584.     The conversion process for message IDs where the site identifier can
  585.     be parsed as a FIDO 5D address in the forms DOMAIN#Z:N/N.P or
  586.     Z:N/N.P@DOMAIN depends from the "domain" (in the FIDO sense of the
  587.     word) of the address.
  588.  
  589.     6.1.1.2.1 Site identifiers that are 5D addresses in FIDONET
  590.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  591.  
  592.     If the site identifier of a message ID is parseable as a FIDO 5D
  593.     address of the form Z:N/N.P@FIDONET or FIDONET#Z:N/N.P (i.e. in the
  594.     FIDONET domain itself), then the DNS name used for the RFC message ID
  595.     must be the DNS equivalent of that address.
  596.  
  597.     This is because MX records exist in the DNS for all of the zone:net
  598.     pairs for 5D addresses in the FIDONET "domain", in the form
  599.  
  600.         p#.f#.n#.z#.fidonet.org
  601.  
  602.     where # is a number without leading zeroes giving the appropriate
  603.     portion of the 5D address.  Therefore this is the conversion that must
  604.     be used.
  605.  
  606.     6.1.1.2.2 Site identifiers that are 5D addresses outside of FIDONET
  607.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  608.  
  609.     Most other "domains" (in the FIDO sense of the word), are free to
  610.     choose their own DNS domain name, but have not yet done so.
  611.  
  612.     Therefore, constructs such as p3.f0.n444.z81.os2net.ftn (which several
  613.     people have INCORRECTLY inferred from other FTS documentation) are NOT
  614.     ALLOWED as the DNS name in an RFC Message-ID.  .ftn is NOT a valid
  615.     top-level DNS domain, for a start, and there is no guarantee that
  616.     OS2NET would adopt that DNS name, either.
  617.  
  618.     (p#.f#.n#.z#.os2net.fidonet.org anyone ?)
  619.  
  620.     6.1.1.2.3 Conversion of local parts
  621.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  622.  
  623.     Where a gateway has recognised a site identifier to represent a FIDO
  624.     5D address that it knows the DNS name for, the local part must then be
  625.     encoded.
  626.  
  627.     According to the grammar in RFC822, any ASCII character (from NUL to
  628.     DEL) is legal in the local part of an RFC822 Message-ID, because
  629.     <quoted-pair> (q.v.) allows any special characters to be escaped.
  630.  
  631.     Since RFC822 transport is merely 7-bit just like type 2.0, 2.0, and
  632.     2.2 message packets are, we use the quoted-printable scheme given in
  633.     chapter 2.
  634.  
  635.     However,
  636.  
  637.     6.1.1.3 Site identifiers that are not recognisable 5D addresses
  638.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  639.  
  640.     No implementation may extend the FIDO 5D address to DNS name
  641.     conversions for site IDs that are given above.  If the message ID is
  642.     "almost, but not quite" a FIDO 5D address, then the message should for
  643.     preference be discarded at the gateway rather than being passed
  644.     through.
  645.  
  646.     Message IDs with abitrary site identifiers are perfectly acceptable to
  647.     this standard, since it ascribes no meaning to site identifiers within
  648.     FIDONET.  However, RFC822 and the existing RFC domain name system
  649.     can only handle a restricted subset of the whole range of FIDO 5D
  650.     addresses.
  651.  
  652.     6.1.1.4 Other site identifiers
  653.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  654.  
  655.     As mentioned before, gateways are allowed to support other site
  656.     identification schemes that are not FIDO 5D addresses, and convert
  657.     site identifiers in those forms to DNS names as they please.
  658.  
  659.     It should be borne in mind when designing such conversion schemes that
  660.     the domain part of an RFC 822 message ID can only contain ASCII
  661.     characters that are not control characters, whitespace, or special
  662.     delimiter characters, because of the definition of <atom> in that
  663.     standard (q.v.).  The quoted printable encoding outlined in chapter 2
  664.     of this document is probably not sufficient for handling full 8-bit
  665.     site identifier schemes, in which case the scheme in RFC1522 should be
  666.     investigated.
  667.  
  668.     6.1.2 Preserving information
  669.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  670.  
  671.     Although this standard recognises two forms for a FIDO 5D address,
  672.     there is only one valid form for that address in the DNS.  For reverse
  673.     conversions to succeed, when an RFC message re-enters 8-bit FIDONET
  674.     (possibly via another gateway), the *exact form* of the original site
  675.     identifier must be reconstructed, otherwise FIDO softwares will treat
  676.     the two message IDs as different.
  677.  
  678.     Although other schemes exist, which encode the 5D address in the local
  679.     part, and use a "generic" domain name of "fidonet.org" (which is not a
  680.     valid host name), it is preferred that the semantics of a message ID
  681.     ("WXYZ local part generated at ABCDE site") be preserved, especially
  682.     as FIDONET sites are visible to the RFC world via the DNS anyway.
  683.  
  684.     It is therefore suggested that the original FIDONET site identifier
  685.     (since it will be 7-bit text) be encoded as a <comment> token
  686.     immediately following the relevant message ID, using quoting to escape
  687.     any embedded punctuation (q.v. the grammar in RFC 822).
  688.  
  689.     6.2 Converting from RFC822 form
  690.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  691.  
  692.     When converting from RFC822 form back to 8-bit FIDONET message IDs,
  693.     gateways should determine whether the address portion of the
  694.     Message-ID is a hostname under the fidonet.org domain.
  695.  
  696.     If it is, a comment token should be scanned for to find the original
  697.     form of the 5D address, and the site identifier should be
  698.     reconstructed from it if found, or from the given DNS name in the form
  699.     DOMAIN#Z:N/N.P if no comment token were present.  The inverse of the
  700.     quoted printable encoding outlined in chapter 2 should then be applied
  701.     to the local part.
  702.  
  703.     Otherwise, the 7-bit RFC822 Message-ID should be stored in the 8-bit
  704.     FIDONET message ID without change.
  705.  
  706.     6.3 Reply linking
  707.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  708.  
  709.     According to RFC1036, message IDs occur in the Message-ID:  and in the
  710.     References:  header for news (echomail).  Although RFC822 specifies an
  711.     In-Reply-To:  header for mail (netmail), it makes it difficult to use,
  712.     because it need not contain a message ID.
  713.  
  714.     The model for message identification used by RFC1036 closely matches
  715.     the model outlined in this standard (it is probable that there is only
  716.     one way to skin this particular cat).  There is thus a direct mapping
  717.     between the primary message ID defined by this standard and the
  718.     RFC1036 Message-ID:  header, and also between the reference message
  719.     IDs defined by this standard and the RFC1036 References:  header.
  720.  
  721.     This means that in normal use the reference message ID list will be
  722.     properly maintained by Usenet softwares.
  723.  
  724.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  725. ÍÍÍ A.0 Discussion on generating unique local parts ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  726.     ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  727.  
  728.     How any given site generates unique local parts is up to it.  So this
  729.     appendix should only be taken as a guideline.
  730.  
  731.     On sites where there is only one piece of software assigning message
  732.     IDs (e.g.  there is only one UA, or the MTA itself assigns message
  733.     IDs), then a simple "take a ticket" scheme could work.    Multiple
  734.     instances of that piece of software running simultaneously would need
  735.     to arbitrate access to that "ticket dispenser" amongst themselves.
  736.  
  737.     A discussion of `sequencers' (which is the proper name for this idea)
  738.     and how atomic operations on them can be implemented, can be found in
  739.     any good computer science textbook on concurrent systems.
  740.  
  741.     Unfortunately, in today's heterogeneous world, it is difficult to the
  742.     point of impossibility to get every piece of software to agree to use
  743.     one single central sequencer.
  744.  
  745.     It is obvious that using just the date/time for a message ID is
  746.     insufficient on multitasking systems, or even on single tasking
  747.     systems that can generate multiple messages per clock tick.
  748.  
  749.     What is less obvious is that it is not a good idea to use the name of
  750.     the software generating the message ID and a sequencer maintained by
  751.     that software as the unique local part.  The problem here is that it
  752.     is not guaranteed that different softwares will use different names
  753.     (especially if they are called "Message Editor" (-:), so it is
  754.     possible that different softwares could generate duplicate local
  755.     parts.
  756.  
  757.     Some form of "product ID code" would of course rectify this, but given
  758.     the amount of software in use and under development these days, a
  759.     centrally administered product ID database hasn't been a viable option
  760.     for decades now.
  761.  
  762.     There are, of course, simpler schemes, that can guarantee to produce
  763.     unique local parts, because they rely on features that are guaranteed
  764.     unique to every individual application running, and do not rely on
  765.     different applications co-operating to use the same central
  766.     facilities, such as a site-wide sequencer.
  767.  
  768.     One commonly used scheme is to use a combination of the current date
  769.     and time and the process and thread IDs of the software creating the
  770.     message ID.
  771.  
  772.     e.g.  1995Jan31.123426.26.1
  773.       or  1995013112343600260001
  774.  
  775.     This doesn't have to be human-readable calendar time, of course.  It
  776.     could equally well be the POSIX 1003.1 time (seconds since The Epoch),
  777.     or the Julian date plus the time of day.
  778.  
  779.     If the time isn't granular enough, a sequence number (which can be
  780.     maintained individually by each process) can be added to increase its
  781.     granularity.
  782.  
  783.     On just about every operating system in the world, including
  784.     multi-user ones, the <time,process,thread,seq> 4-tuple will be unique
  785.     on one machine *forever* (or until the clock wraps around, at least).
  786.  
  787.     e.g.  1995Jan31.123426.26.1.2
  788.       or  19950131123436002600010003
  789.  
  790.     On multiple machine sites, where all machines share the one site
  791.     identifier, the above scheme can be extended to include the "hidden"
  792.     local machine name, which will be assumed to be made available (in
  793.     some fashion) to the softwares generating the message IDs.
  794.  
  795.     This yields a unique <machine,time,process,thread,seq> 5-tuple.
  796.  
  797.     e.g.  utopium.1995Jan31.123848.26.1.4
  798.       or  utopium.19950131123907002600010005
  799.  
  800.     Again, the "intra-site" machine name can be anything, from the local
  801.     uname() (for UNIX people) to the NETBIOS machine name (for PC based
  802.     LAN systems).
  803.  
  804.    ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  805. ÍÍÍ Bibliography and Author ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  806.    ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  807.  
  808.     [FTS0001] A Basic FIDONET Technical Standard, version 15.  Randy Bush,
  809.               Pacific Systems Group.  FIDONET#1:105/6.0.  30th August
  810.               1990.
  811.  
  812.               ( Defines the type 2.0 packet message transport format.  )
  813.  
  814.     [FTS0009] A standard for message identifiers and reply chain linkage,
  815.               version 1. Jim Nutt.    FIDONET#1:114/30.0.  17th December
  816.               1991.
  817.  
  818.               ( Defines the MSGID/REPLY kludges.  )
  819.  
  820.     [FSC0034] Gateways to and from FIDONET.  Technical, administrative,
  821.               and policy considerations.  Randy Bush, Pacific Systems
  822.               Group.  FIDONET 1:105/6.0.  30th August 1990.
  823.  
  824.               ( Discussion on features that should be preserved across
  825.                 gateways, and on good gateway behaviour in general.  )
  826.  
  827.     [FSC0039] A type 2 packet extension proposal, version 4. Mark A.
  828.               Howard.  FIDONET#1:260/340.  29th September 1990.
  829.  
  830.               ( Defines the type 2.0+ packet message transport format.    )
  831.  
  832.     [FSC0045] A proposal for a new packet format, version 1. Thom
  833.               Henderson.  FIDONET#1:107/542.1.    17th April 1990.
  834.  
  835.               ( Defines the type 2.2 packet message transport format.  )
  836.  
  837.     [FSC0068] A proposed replacement for FTS-0004, version 1. Mark Kimes.
  838.               FIDONET#1:380/16.0.  13th December 1992.
  839.  
  840.               ( Defines kludge lines.  )
  841.  
  842.     [RFC0822] Standard for the format of ARPA Internet text messages.
  843.               David Crocker, University of Delaware.  13th August 1982.
  844.  
  845.               ( Defines the grammar and semantics of RFC messages.    )
  846.  
  847.     [RFC1036] Standard for the interchange of USENET messages.    M Horton,
  848.               AT&T bell labs; and R. Adams, Centre for seismic studies.
  849.               December 1987.
  850.  
  851.               ( Defines changes to the grammar and semantics of RFC822
  852.                 that are required for news instead of mail, including
  853.                 reply linking.    )
  854.  
  855.     [RFC1521] MIME (Multipurpose Internet Mail Extensions) Part One:
  856.               Mechanisms for specifying and describing the format of
  857.               Internet message bodies.    N. Borenstien, Bellcore; and N.
  858.               Freed, Innosoft.    September 1993.
  859.  
  860.               ( Defines Quoted Printable encoding of text.    )
  861.  
  862.     [RFC1522] MIME (Multipurpose Internet Mail Extensions) Part One:
  863.               Message header extensions for non ASCII text.  K. Moore,
  864.               University of Tennesee.  September 1993.
  865.  
  866.               ( Defines how to use Q-P encoding in message headers.  )
  867.  
  868.     [TYPE2EXT] An extension to type 2.0, 2.0+, and 2.2 message transport
  869.                formats to eliminate most kludge lines from the message
  870.                body.  Jonathan de Boyne Pollard.  FIDONET#2:440/4.0.
  871.                [ Not yet released.    ]
  872.  
  873.     ÄÄÄÄÄÄÄÄÄÄÄ
  874.     Jonathan de Boyne Pollard
  875.     FIDONET#2:440/4.0
  876.